DTS Derivation Path

The DTS derivation path defines the relation between two DTS business objects: the input business object and output business object. It returns the output business object data based on the input business object data, where the logic is defined either by a table field relation or by logic written in ABAP. The result of the function is stored in a DTS derivation path table. The output business object table is filled from the DTS derivation path table(s), based on the settings Include, Exclude and Input group. For more information, see the chapter Setting up the Derivation of DTS Business Object Values.

NOTE The derivation path naming convention is designed to be explanatory:
<INPUT_BO>_<OUTPUT_BO>(<relation table>) *.
*Small deviations are possible as long as the name remains explanatory.

There are three types of derivation path:

Replication path (RFC): Type R. This is the path used to replicate data from a business object located in a different system/client via RFC connection. The replication run ID and RFC servers must be defined in the step Maintain run ID. The replication path is then defined by name of the remote business object and the output business object. Once the derivation is finished on the remote system, data is made available for copying via the defined replication path. For more information see the chapter Setting the BO Replication.
Initialization path: Type I. This is the path for the initialization of the output object. It does not contain any input business object. The data is derived to the output business object from a table.
Single path: Type S. This is the standard derivation path.

For more details about the preselection process, see the chapter DTS Preselection.

The DTS derivation path maintenance screen consists of two areas: the upper one contains general data and the lower one contains the technical definition of the derivation path.

The toolbar provides the following functions:

Save (Ctrl+S): Saves your changes after editing.
Edit/display (Ctrl+F1): Switches between edit mode and display mode.
Setup > Expert mode: Enables expert mode, in which all consistency checks are disabled. This is used only for content build purposes. Do not use this function in customer projects.

General data:

Run ID: Loaded DTS run ID.
Path: Technical name of the DTS derivation path.
Path type: Specifies the path processing type:
- S = single path
- R = replication path
- I = initialization path
Description: Short text describing the derivation function. This field is generated after the input and output business objects are entered.
Input business object: Name of the DTS business object used as the input for the derivation function. This parameter is not visible for the initialization path and remote path.
Input business object type: Specifies the business object type. This parameter is not visible for the initialization path and remote path:
- S = standard business object
- C = compounded business object
- I = InfoObject-based business object
Remote business object: Text field for name of the business object on the remote server.
Output business object: Name of DTS business object used as output for the derivation function.
Output business object type: See the input business object type.
Package size: Technical parameter that defines the number of records according to which the processed data is split into packages. If left empty, the default parameter defined in the expert settings is used. Note that changing this parameter can impact the performance.

Technical definition: This area differs based on the derivation path type as well as based on the single path processing options: Standard table-based processing and ABAP-based processing.

The standard table-based processing has the following attributes:
- Table: Name of the table used for connecting the input and output business objects, also known as the derivation table.
- Table description: Short text description of the table from the SAP DDIC.
- Four pages to further customize the path (not available for the replication path type):
  1. 1. Field mapping page
    
    This page defines the mapping between the DTS business objects and the field in the table. The mapping is performed in an ALV grid structure with the following structure:
    - Input/output: Specifies whether the business object is the input or output business object.
    - Business object: Specifies the name of the business object.
    - Field name: Specifies the field of the table. The field must match the definition of the business object.
      - Since release 24.01, the field name accepts fixed values. The reason is to support generated CO-PA tables. The following options are available:
        
        Fixed values must be wrapped in single quotes: '
        
        A single quote inside of the fixed value must be escaped using another single quote
        
        EXAMPLE Fixed value ‘YOU’'RE' > Is resolved as YOU’RE
        
        Concatenation is specified using a pipe symbol: |
        
        EXAMPLE ‘EOIDEA’|PAOBJNR > Concatenation of a fixed value and a field
        
        The offset and length operations are supported on each concatenated element by specifying +<offset> and (<length>) in the expression.
        
        EXAMPLE In this example, the field name is ABCDEFGH and the expression is as follows:
        * ‘TEST’|<FIELDNAME>(5)|'FIX' (i.e. the field name is wrapped between two fixed values and only the first five characters of the field name will be used.)
        * The expression is resolved as TESTABCDEFIX
        
        The offset and length specified in dedicated columns (outside the expression) will be applied after resolving the expression.
        
        EXAMPLE In this example, the field name is ABCDEFGH and the expression is as follows:
        ‘TEST’|<FIELDNAME>(5)|'FIX', OFFSET = 1, LENGTH = 10 (i.e. the field name is wrapped between 2 fixed values with only the first 5 characters of the field name to be used and with offset shift and overall length definition.)
        * The expression is resolved as ESTABCDEFI
    - Offset: Specifies the offset of the value in case of an intransparent field.
    - Length: Specifies the length of the value in case of an intransparent field.
  2. 2. Condition – select option page
    
    This page defines the conditions under which the output data is collected from the input business object table. The page shows a standard select option structure for the selected fields from the table. Only records matching the defined selection are processed further.
    
    To define the selection, click Select option in the ALV grid toolbar (accessible in edit mode only).
    
    The following options are available:
    - The select options of the selected fields (see the filter button below) of the table to define their values as condition criteria in order to apply the derivation.
    - Accept: Confirms the fields and values chosen in the select options.
    - Cancel: Cancels the operation.
    - Filter: Defines the fields for which the select option is generated. The maximum number of supported fields is 30.
  3. 3. Condition – WHERE condition page
    
    In cases when the standard select option cannot provide the required data selection or the select option is not efficient, DTS offers the option to write your own WHERE condition. The WHERE clause must be defined as one long string. Do not split it into separate lines.
    
    For example, for material documents with materials that have the string 123 at offset #10, the WHERE clause will be:
    
    MATNR LIKE ‘__________123%’
  4. 4. Technical settings page (available only in the single path type):
    - Initial values: If selected, the blank records of the input business objects are considered as relevant.
    - Partial relevant values: If selected, you can define the processing of partially relevant data:
      - Save: Keep the partially relevant data.
      - Delete: Do not process the partially relevant data.
      NOTE Partially relevant data is data for which an output business object value belongs to a relevant as well as a not relevant input object value. For example, material MAT1 belongs to plant 1000, which is part of the scope, as well as plant 2000, which is not part of the scope.
    - Force usage of lookup cursor: Changes the way data is selected:
      - Blank: Uses a JOIN operation on the table chosen for derivation (MSEG in the image above) with the data in the input business object tables.
      - Chosen: Uses a SELECT with an open cursor on the table chosen for derivation with a lookup into the input business object table.
        
        NOTE You can test or debug the standard derivation via the ABAP report /DVD/PATH_PRESEL_TASK. For more information, see the chapter Execute and Monitor Preselection.

The ABAP-based processing has the following attributes:

Parallelize based on input object data: Sets the automatic parallelization of the ABAP-based paths based on the values of the input DTS business object table. These partitions are generated in the downtime during the preselection phase.

Number of partitions: Sets the number of partitions created during the preselection phase. The default value is 10 parallel partitions.

NOTE The input business object into the ABAP path must have good granularity to efficiently split the data into the 10 partitions. If the input business object table only has a few entries, parallelization does not make sense.

Transform table: Allows you to decide whether to use the mode Transform row or Transform table. The default value is <space>, which means Transform row. We recommend selecting this option in order to activate Transform table mode (see below).

1. Transform row mode: Allows you to process a single row for the input business object. The processed row is then returned to the derivation path table. The processing logic needs to be entered instead of the placeholders ******INSERT YOUR CODE HERE into the form transform_row (see the template below). The form is called in the loop from the main generated program. The form input is limited to four objects. If you require more objects, use transform table mode instead.

ABAP template for transform row

Copy

*&---------------------------------------------------------------------*
*&      Form  transform_row
*&---------------------------------------------------------------------*
*
*       When working with one input row, returning one output row
*       for one input record, the output can be:
*       - One record
*       - Nothing
*       Fields with the pattern IV_FIELD* only exist because the
*       form interface is required. Do not use them.  *
*----------------------------------------------------------------------*
*      -->iv_bukrs     text
*      -->IV_FIELD2     text
*      -->IV_FIELD3     text
*      -->IV_FIELD4     text
*      -->cv_kunnr     text
*      -->CV_FIELD2     text
*      -->CV_FIELD3     text
*      -->CV_FIELD4     text
*      -->CB_RELEVANCE  text
*----------------------------------------------------------------------*
FORM transform_row
  USING
    iv_bukrs      TYPE bukrs
    iv_field2      TYPE any
    iv_field3      TYPE any
    iv_field4      TYPE any
  CHANGING
    cv_kunnr      TYPE kunnr
    cv_field2      TYPE any
    cv_field3      TYPE any
    cv_field4      TYPE any
    cb_relevance   TYPE xfeld.

  CLEAR:
    cv_kunnr,
    cv_field2,
    cv_field3,
    cv_field4,
    cb_relevance.


******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE


ENDFORM.                    "transform_row

2. Transform table mode: Allows you to process a complete input business object table in the ABAP implementation. The processed table is then returned to the derivation path table. The processing logic needs to be entered into the form transform_table (see the template below).

ABAP template for transform table

Copy

*&---------------------------------------------------------------------*
*&      Form  transform_table
*&---------------------------------------------------------------------*
*
*       Working with one input table, the returning output table
*       for one input record in table output can be
*       -one record
*       -nothing
*       -multiple records
*
*----------------------------------------------------------------------*
*      -->IT_INPUT   text
*      -->ET_OUTPUT  text
*----------------------------------------------------------------------*
FORM transform_table
  USING
    it_input  TYPE STANDARD TABLE
  CHANGING
    et_output TYPE STANDARD TABLE.

******PREDEFINED TEMPLATE CODE START******
******NOT REQUIRED TO USE – JUST FOR HELP******

  CLEAR et_output.

  FIELD-SYMBOLS:
  <ls_input>   TYPE ANY,
  <ls_output>  TYPE ANY.

  DATA:
  lo_input_struct   TYPE REF TO data,
  lo_output_struct  TYPE REF TO data.

  CREATE DATA lo_input_struct LIKE LINE OF it_input.
  ASSIGN lo_input_struct->* TO <ls_input>.

  CREATE DATA lo_output_struct LIKE LINE OF et_output.
  ASSIGN lo_output_struct->* TO <ls_output>.

*******PREDEFINED TEMPLATE CODE END******

******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE
******INSERT YOUR CODE HERE

ENDFORM.                    "transform_table

ABAP variant: Name of the ABAP code with the ABAP-based processing derivation.
Create: Button to create the ABAP variant. Allows you to edit the generated template forms.
Description: Short text describing the ABAP logic.
Display: Button to show the ABAP variant code.
Edit: Button to edit the ABAP variant code.
Delete: Button to delete the ABAP variant.
Test: Button to test the results of the ABAP variant. This function is executable in edit mode only. After you click Execute, the example input parameters need to be edited. These parameters are then passed to the implemented ABAP variant. The result is displayed in an ALV grid.